Extract selectors from useResolveEditedEntity hook #67031
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
youknowriad
added
the
[Type] Code Quality
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
I found that the same getTemplateId selector already existed before but was part of the edit-post store. This allows us to remove it and remove the code duplication. |
|
Size Change: -76 B (0%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
jsnajdr
reviewed
Nov 15, 2024
| homepagePostType: homePage?.postType, | ||
| homepagePostId: homePage?.postId, | ||
| }; | ||
| }, [] ); |
There was a problem hiding this comment.
Could you just return homePage from the useSelect instead of creating an extra object?
There was a problem hiding this comment.
If I do I have to memoize the getHomePage selector and I was lazy :P
There was a problem hiding this comment.
I memoized the selector in c33d560 let me know if this is correct
packages/edit-site/src/components/editor/use-resolve-edited-entity.js
Outdated
Show resolved
Hide resolved
jsnajdr
reviewed
Nov 15, 2024
| select( STORE_NAME ).getEntityRecord( 'root', 'site' ), | ||
| select( STORE_NAME ).getDefaultTemplateId( { | ||
| slug: 'front-page', | ||
| } ), |
There was a problem hiding this comment.
The trouble with this is that the getDefaultTemplateId call triggers the resolver and a wp/v2/templates/lookup REST request. But the actual selector doesn't always call getDefaultTemplateId. If there is a valid homepage, it returns early and the REST request wasn't needed.
Because the select is same-store we can solve this by calling the plain selector function in the get-dependants callback. That's exactly what we need: just read the data from state and don't do any side effects.
I don't know how we would solve this if the select was cross-store. Interesting problem for @ellatrix or @Mamaduka who have plenty of experience working with complex selectors: do we have any existing prior art for this?
There was a problem hiding this comment.
you're right, I updated here to use the selectors directly, I think that's enough.
jsnajdr
approved these changes
Nov 18, 2024
|
I agree that the code for the selectors is still a bit challenging. Mostly because we're recreating the template hierarchy logic in the frontend basically. That said, I believe moving these to selectors bring clarify in the sense that it's clear that one selector is about retrieving the home page (whether that's a template or page) and the other is about retrieving the template that is going to be used for a current page. |
youknowriad
deleted the
update/extract-selectors-from-use-resolve-edited-entity
branch
|
@youknowriad, I just noticed that the editor started doing two template lookup calls after this merged. Was that intentional? Screenshot
|
|
Not intentional no, maybe we're not waiting for the home page to be resolved properly before loading the second selector or something. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related #66921
What?
As the site editor is growing to become a multi page app, it doesn't really make sense to have an edited post type and context state in it.
That state is forcing us today to have a two way synchronization mechanism between the url and the state causing some issues related to performance and some hidden bugs at times.
Ideally the routes would just pass the post type, post id to the editor component. The current PR helps to go in that direction by extracting some selectors that the routes will be able to use to either fetch a template for a given postType/postId or fetch the home page.
Testing Instructions